Traffic scheduling system

ABSTRACT

A system for scheduling traffic capable of planning journeys, each having a plurality of transit points, comprising means for receiving scheduling criteria including transit point data and map data, said map data comprising one or more routes, each route defined in terms of a plurality of route-sections, a data repository comprising historical speed data for each route-section, historical speed data for a particular route-section being represented for a predetermined time on a particular day, means for generating forecast speed information for a traffic unit on each said route-section based on said historical speed data, and processing means for planning a journey including a plurality of transit points in dependence on said scheduling criteria and forecast speed information. A method of operating a traffic scheduling system and a computer program are also claimed.

FIELD OF THE INVENTION

The present invention relates to methods and apparatus for trafficscheduling and particularly for scheduling vehicles on road journeys.However, it also applies to shipping operations, aircraft as well asrail journeys and multi-modal journeys which combine movement in two ormore modes of transit.

The preferred embodiment of the present invention uses two forms oftraffic planning data for scheduling vehicle journeys. First, pre-eventtraffic planning data is used in the form of a forecast of probablevehicle speed over a particular stretch of road at a particular time,e.g. a particular time of the day on a particular day of the week. Suchdata is based upon analysis of actual travel times gained from thevehicles which traverse a particular stretch of road and the knowledgethat similar circumstances may take place. Secondly, a current trafficdelay reporting system provides real time data in terms of actualvehicle speeds over a particular stretch of road at a particular time,e.g. a particular time on a predetermined day. In addition a feedbackloop compares actual traffic speed data with the pre-event trafficplanning data already provided in order to improve the quality of thepre-event data. This information is useful to both traffic planners andthose drivers planning and undertaking journeys in order that they maybe able to accurately calculate their specific journey times.

For the purposes of this specification the term “traffic planner”includes any person or apparatus capable of planning or undertaking ajourney or multiple journeys. The ability to obtain live traffic delaydata also allows those planning and undertaking journeys to re-plan andre-route vehicles in order to avoid known delay spots. The term “transitpoint” used herein means a stopping place on a journey, for example forloading or unloading payloads and delivery items.

BACKGROUND ART

Commercial vehicle routing and scheduling methods have been in existencefor many years, providing a minimum mileage estimate for single ormultiple vehicle journeys of one or more drops or stopping places. Onesuch known system is disclosed in a paper entitled “Scheduling Vehiclesfrom a Central Depot to a Number of Delivery Points” Clark, G., andWright, J. W., Operations Research (1963), 11, 568-581. Known methods,however complex, rely on the determination of an average vehicle speedfor a particular type of vehicle (for example, an articulated vehicle)over a defined type of road (for example, a motorway). Moresophisticated systems apply congestion factors to potential travelspeeds as percentage reductions in the defined speed between specifictimes on a particular day.

In practice, vehicles travel over different stretches of any road atdifferent speeds depending upon the time of day, type of vehicle, volumeof traffic, restrictions such as road works, or specific trafficincidents such as accidents or breakdowns. Since actual traffic speedsare affected by traffic congestion of one type or another, forecasttravel times used in vehicle routing and scheduling techniques areinaccurate.

In the commercial sector, the results of inaccurate forecasts areparticularly significant upon the productivity of both the resources andstaff undertaking a journey. In the last few years, vehicle routing andscheduling methods have lost favour with operational managers due to thegap between planned journey times and actual journey times. For example,in a commercial operation delivering orders to customers within requiredtime windows, it is estimated that more than 18% time contingency isbuilt in to the daily traffic plan to ensure a 98% probability ofsuccess in achieving all the deliveries within the desired time windows.Furthermore extension of the working day (often resulting in the paymentof overtime to both drivers and warehouse staff) may be anotherconsequence if the delivery time is extended due to traffic congestion.Journey planners are also criticised because the 18% time contingencybuilt into a traffic planning schedule results in productive time beingwasted on a good day.

Therefore, to date the majority of telematics systems have been limitedto cars and applications to support heavy goods traffic and passengertraffic have been largely ignored. Preferred embodiments of thisinvention focus upon the application of this technology for heavy goodsand passenger traffic. However, the invention is not limited to this,the invention having applications in other fields, including thenon-commercial sector, such as emergency services or other commercialapplications such as aircraft, rail and shipping operations etc.

An objective of preferred traffic scheduling systems is to minimise theimpact of both predicted and unpredicted traffic delays for thecommercial vehicle operator. This invention seeks to provide an improvedmethod of scheduling traffic.

According to a first aspect of the present invention, there is provideda method of operating a traffic scheduling computer system for planningjourneys, each journey having a plurality of transit points, methodcomprising receiving scheduling criteria including transit point data,receiving map data, said map data comprising one or more routes, eachroute defined by a plurality of route-sections, receiving forecast speedinformation for a traffic unit on each said route-section, the forecastspeed for a given route-section depending on historical speed data forthat route-section at a predetermined time on a particular day; andplanning a journey including a plurality of transit points in dependenceon the scheduling criteria and forecast speed information.

In preferred embodiments, the scheduling criteria comprise one or moreof availability data, distance data, time data, depot data, customerdata, and product data. The availability data might comprise, forexample, availability information for one or more of a prime mover, atrailer and a driver. The forecast journey speeds and times are derivedat least in part from historical speed data acquired by means offloating vehicle data collection units or other mobile data collectionmeans. Live traffic monitoring may also be performed by means offloating vehicle data collection units or other mobile data collectionmeans.

According to a second aspect of the present invention, there is provideda computer system for scheduling traffic, capable of planning journeyseach having a plurality of transit points, the system comprising meansfor receiving scheduling criteria including transit point data and mapdata, said map data comprising one or more routes, each route defined interms of a plurality of route-sections, a data repository comprisinghistorical speed data for each route-section, historical speed data fora particular route-section being represented for a predetermined time ona particular day, means for generating forecast speed information for atraffic unit on each said route-section based on said historical speeddata, and processing means for planning a journey including a pluralityof transit points in dependence on said scheduling criteria and forecastspeed information.

According to a third aspect of the present invention, there is provideda method wherein at least a portion of the planned journey is re-plannedaccording to re-scheduling criteria after the traffic unit has embarkedupon the journey. Preferably, said re-planning step is triggered inresponse to an unpredicted traffic event or operational failure. Inpreferred embodiments said unpredictable event data comprises livetraffic reports and/or data derived from live traffic monitoring.

According to a fourth aspect of the present invention, there is provideda method wherein a first journey solution is determined in a firstalgorithm processing step and an improved journey solution is determinedin a further algorithm processing step.

According to a fifth aspect of the present invention, there is provideda method in which unpredictable events are categorised according to ageographic region in which they occur and information on theunpredictable event is communicated to traffic units associated with arelevant geographical region.

According to a sixth aspect of the present invention, there is provideda method in which forecast speed information for a route-section isrecorded and compared with actual speed data for that route-section inorder to provide a measure of reliability or feedback to the trafficscheduling algorithm.

According to a seventh aspect of the present invention, there isprovided a method in which floating vehicle probes are selectivelyactivated for monitoring based on a probability of the traffic unitcarrying the probe being on a predetermined route-section.

LIST OF DRAWINGS

The invention will now be described, by way of example only, withreference to the accompanying drawings in which:

FIG. 1 is a schematic diagram illustrating components of a preferredtraffic scheduling computer system;

FIG. 2 illustrates a preferred system for on-board live data collection;

FIG. 3 schematically illustrates components for producing a RoadTimetable™ data repository suitable for use in the traffic schedulingsystem of FIG. 1;

FIG. 4 illustrates a method for determining vehicle routes suitable foruse in the traffic scheduling system of FIG. 1;

FIG. 5 illustrates a system for reporting live traffic delays in thetraffic scheduling system of FIG. 1;

FIG. 6 schematically illustrates components for dynamic vehiclere-planning in the traffic scheduling system of FIG. 1;

FIG. 7 illustrates components for live vehicle monitoring;

FIG. 8 illustrates the feedback of data applying to a vehicle journey;

FIG. 9 illustrates a preferred system for vehicle route planning anddynamic route planning;

FIG. 10 illustrates examples of input data for deriving a plannedvehicle route;

FIG. 11 illustrates a sequential insertion based algorithm;

FIG. 12 illustrates a parallel insertion based algorithm;

FIG. 13 illustrates possible improvement phases for use in the trafficscheduling system of FIG. 1;

FIG. 14 illustrates a simulated annealing improvement algorithm;

FIG. 15 illustrates a Tabu search improvement algorithm;

FIG. 16 illustrates an algorithm used to calculate the impact ofpotential traffic congestion;

FIG. 17 illustrates an algorithm for calculating the impact of customerdrop delays; and

FIG. 18 represents an algorithm which can be used for dynamic vehiclere-planning.

DESCRIPTION OF THE PREFERRED EMBODIMENT

A preferred embodiment of the present invention will now be described,by way of example only. Embodiments of this invention may be used forthe planning of routes and/or schedules for all types of transport,including but not limited to cars, ambulances or other emergency ormilitary vehicles, heavy goods vehicles, buses, coaches, aircraft,shipping and any other modes of transport.

The traffic scheduling computer system of FIG. 1 records daily trafficdata by section of road (for example, between specific motorwayjunctions). It has been indicated that approximately 75% of congestionis predictable both in probability of occurrence and in the delay timeexpected. Such predictable traffic congestion includes that due tovolume of traffic, road works, wide-load movements or extended poorweather conditions.

The ability to predict such pre-event traffic congestion is based uponthe collection, interpretation, analysis and presentation of historicand-forecast data both from within the public domain and from specificsources such as vehicles which are fitted with a probe to detectlocation and speed, which when collected is known as ‘floating vehicledata’ (FVD)™. The outcome of this analysis is a list of “pre-event”traffic delays which is an aspect of the preferred embodiment of thepresent invention. The summary of the data analysis presents a forecastof travel speeds for selected types of vehicles over a specific roadlength at specific times of the days of the week, known as the “RoadTimetable™”. Preferred embodiments can record speeds against calendardates so that all patterns of traffic behaviour can be identified.

The presentation of forecast travel speeds for specific road lengths andtimes of the day, allows the journey planner to add this data to avehicle routing and scheduling algorithm to produce more accuratevehicle travel plans. The application of the “Road Timetable™” in avehicle routing and scheduling method is a further aspect of thepreferred embodiments of this invention. A vehicle routing andscheduling method based upon the use of this type of predictable traveltime for each section of road on a journey provides an improvement overknown journey planning systems. However, such systems still have adegree of error between the planned time and the actual time whichcorresponds to approximately 25% of unpredictable traffic delays.

Unpredictable traffic delays, such as those caused by road trafficaccidents (RTA) may also be identified as they occur by means of vehicleprobes which are within the area in which the delays are actuallyoccurring or from traffic reports on particular incidents. Theseunpredicted incidents may be reported separately in association with ageographic location, for example a section of road in a postcode sector.Such information may be sent to both traffic planners and drivers bymeans of any suitable form of communication. Actual vehicle speed inunpredicted traffic scenarios may be compared with the speed forecastfrom historic data, thereby making it possible to determine a newpredicted delay time. The calculation and communication of this currenttraffic delay due to unpredictable events is a further aspect of thepreferred embodiment of this invention.

By monitoring vehicle progress in real time it is possible to reportwhere traffic delays are occurring so journey planners can identify orselect vehicles which are affected by the unpredicted trafficincident(s). Upon identification of a vehicle affected by anunpredictable traffic delay and determination of the delay time arisingfrom the or each incident the information is supplied to a ‘dynamicvehicle re-planning system”. The dynamic vehicle re-planning system canfor example enable re-routing of vehicles mid journey to avoid theunpredicted traffic delay and/or re-plan the drop sequence of a deliveryload. Preferred vehicle re-planning systems can be included within orassociated with general vehicle routing and/or scheduling systems.

Preferred traffic planning and re-planning systems are further enhancedif for example multiple elements of the delivery resource (trailer,prime mover and driver) are considered as separate but inter-relatedresources. This can be facilitated by monitoring a prime mover and atrailer separately and using driver and vehicle recognition systems.Thus, the driver and vehicle(s) can be monitored separately. Thedriver's identity is recognisable to the data collection unit on atleast the prime mover. Considering vehicle routing and scheduling tasksin terms of a number of separate resources (trailer, prime mover anddriver) offers many alternatives in the event of an unpredicted trafficdelay. The application of the knowledge of the delay time from anunpredicted traffic incident in the dynamic vehicle re-planning is afurther aspect of the preferred embodiment of this invention.

FIG. 1 identifies component parts of the preferred computer system andhow they link together. Each component part has both inputs and outputsin its own right, a detailed description of which follows. Somecomponent parts described herein may be obtained on the commercialmarket from independent vendors, the functionality and construction ofothers will be apparent to a skilled person from the description herein.The preferred embodiment combines a number of novel aspects whichinclude: the Road Timetable™—an information resource containingforecasts of traffic speeds by type of vehicle over a particular sectionof road on a defined day and time accounting for known traffic delays;the application of the Road Timetable™ in commercial vehicle routing andscheduling, the calculation and rapid communication of potential delaytime in relation to unpredictable traffic delays; and the application ofsuch delay time in dynamic vehicle re-planning. In the context of thisdescription the term “dynamic” means while a vehicle is en-route, i.e.has already embarked on a planned journey.

Referring to FIG. 1, a preferred traffic scheduling system 100 comprisesa Road Timetable™ 110. The Road Timetable™ 110 is an informationresource which supplies forecast information taking into accounthistorical traffic data to a Vehicle Route Planner 120. The forecastinformation is in the form of a database recording speeds by vehicletype, road section and temporal characteristics. The Road Timetable™ isdescribed hereinafter with reference to FIG. 3.

The Vehicle Route Planner 120 calculates the best route for the or eachproposed journey, taking into account the start location, destinationlocation and any transit points which may be relevant. The Vehicle RoutePlanner 120 and its modes of operation are described in more detaillater with reference to FIG. 4. The Vehicle Route Planner 120 outputs anindication of the best route or routes to a Dynamic Vehicle Re-planningstage 130.

The Dynamic Vehicle Re-planning stage 130 is capable of adjusting aroute for a vehicle which is already embarked on a route determined forit. That route may have been determined by the Vehicle Route Planner 120or an earlier re-planning process of the dynamic re-planner 130. Thedynamic re-planning stage 130 receives information from a live delayreporting facility 140 and a Live Vehicle Monitoring Facility 150. TheLive Vehicle Monitoring Facility 150 measures a real time delay byrecording current vehicle speeds by means of vehicle-bound, i.e.“on-board” data collection units (DCUs). This collection of data isrepresented by box 160 of FIG. 1.

Further descriptions of the Dynamic Re-planning stage 130, the LiveDelay Reporting Facility 140, the Live Vehicle Monitoring Facility 150,and the on-board data collection units are provided hereinafter withreference to FIGS. 6, 5, 7 and 2, respectively.

In this embodiment, the route determined by the traffic schedulingSystem 100 is output from box 130 to the hand held terminal as describedin FIG. 6 but this configuration should not be limiting and differentcommunication means may be employed in other embodiments.

A Post Trip Data Module 170 receives route information from the DynamicVehicle Re-planning stage 130 and the Live Data Collection Unitsrepresented by box 160. These inputs are processed and results fed backto the Road Timetable™ 110 and Vehicle Route Planner 120. The processingperformed by the Post Trip Data stage 170 compares a log of actualdelays occurring over time with the planning and re-planning informationoutput at the corresponding time so that deviations can be taken intoaccount in the next schedule determination. This is described in moredetail with reference to FIG. 8.

FIG. 2 illustrates the technique by which a vehicle collects live dataabout its position and operational characteristics. This technique isdescribed because the characteristics of live data are used in thegeneration of the Road Timetable™ 110 and in the determination ofunpredicted traffic delay. A vehicle which contains a data collectionunit is referred to herein as a “probe” vehicle.

The precise location of a probe is defined by its latitude andlongitude. This is obtained through calculations on information derivedfrom a Global Positioning System (GPS) receiver fitted to the vehicle.The GPS receiver obtains at least three direct line of site readingsfrom the GPS Satellites 220 using a well known technique to obtain anaccurate vehicle location. In Europe such GPS receivers may be obtainedfrom a number of commercial suppliers produced under the GlobalAutomotive Telematics Standard (GATS) issued by Comité Européen deNormalisation CEN. Similar receivers known outside Europe are suitablefor use in accordance with the present invention.

A combination of vehicle positions obtained at predetermined timeintervals throughout a journey, is known as Floating Vehicle Data 210.This Floating Vehicle Data 210 is the basis for the calculation ofvehicle speed and direction of travel at a particular position.

In this embodiment, each probe contains means for transmitting locationinformation and/or information derived therefrom to a central datacollection point 240. Floating Vehicle Data 210 may be accumulatedon-board the vehicle by a data collection unit 230. This may be storedin a suitable vehicle-bound storage device or transferred to anothersuitable storage device, such as a Hand Held Terminal (HHT) or aPersonal Digital Assistant (PDA) 250. Alternatively, or in additions,the Floating Vehicle Data may be transmitted directly from the datacollection unit to a central data collection station 240. Live data mayalternatively be sent to the central data collection point 240 via aHHT/PDA 250 by immediate communication using, for example, ShortMessaging Service (SMS) or General Packet Radio System (GPRS). A skilledperson would be able to select a suitable communications configurationfor a particular application.

Where Floating Vehicle Data 210 is accumulated on board, it may be heldon-board 230, for example in a Hand Held Terminal (HHT/PDA) 250 for thedriver or passenger to use as part of an independent navigation system.In this case, data from the HHT 250 may be transferred to the DataCollection Station 240 later by any suitable means including, but notlimited to, historic data direct base station or radio download uponreturn to base.

Live data from the Data Collection Station 204 may be used by a VehicleScheduler 260 to track the progress of vehicles on their predefinedroute. Historic data will be obtained from the On-board Data Collectionfunction 230 and analysed as Post Trip Data 170 to update the RoadTimetable™ (see FIG. 8).

FIG. 3 is a schematic diagram illustrating the Road Timetable™ datastore. The positional data is collected throughout a journey from aplurality of Vehicle Probes 310. The Vehicle Probes 310 are distributedover a predetermined geographical area permitting the calculation ofhistoric average vehicle speeds for different types of vehicles onspecific road sections at specific times of the day on particularcalendar days. In addition, or in the alternative, traffic data may becollected from other sources such as fixed sensors or another technologyindicating location (e.g. mobile phones). This historical data resourceis called Historic Floating Vehicle Data 320. Historic Floating VehicleData 320 is presented as forecast vehicle speeds, classified by type ofvehicle and by time of day on a predefined stretch of road. For example,entries in the Road Timetable™ 110 may indicate the historic averagespeed of a freight vehicle, at 15 minute intervals, on the portion ofthe M1 between junctions 19 and 20, Northbound). The Historic FloatingVehicle Data 320 is passed through a number of statistical analysesstages to determine the average speeds from the plurality of detectedvehicle probes 310 for each vehicle type at specific time intervals(e.g. every 15 minutes) and to place more statistical weight upon themore recently collected data.

The information in the Road Timetable™ 110 is thus the presentation ofthe historic traffic speeds averaged over a time period for a specificroad length at specific times. This data thus incorporates allpredictable traffic delays due to factors such as volume inducedcongestion of traffic or long term road works. The information in theRoad Timetable™ 110 is presented such that it can be used in the processof planning vehicle routes and schedules 120. Further, Post Trip data170 is fed back to enhance the Historic Floating Vehicle Data 320. TheRoad Timetable™ 110 also contains additional data relevant for planningvehicle routes for vehicles of various types. This additional data canbe obtained from sources in the public domain 510 and/or from sourcesoutside the public domain 520.

The information contained in Road Timetable™ 110 may include differenttypes of information which may be presented in many different forms. TheRoad Timetable™ 110 is preferably presented in electronic form and thedata updated periodically by means of a web browser or other suitablemeans.

Users may choose from a number of criteria known to traffic planners,for example, whether the following information should be made available:

-   -   Road link identification means    -   Link length    -   Day of the week (of which eight are recognised, namely Sunday to        Saturday and Bank Holiday)    -   Time of day (in defined intervals)    -   Speed through link    -   Delay (time)    -   Reason for delay (if known)    -   Vehicle type    -   Inbound links    -   Outbound links    -   Restrictions in link (for example, low bridge or level crossing)    -   Restrictions for use (times when heavy goods vehicles        restricted)    -   Weight restrictions    -   Bridge height or road width restrictions    -   Toll charges

The application of the Road Timetable™ 110 to the process of planningvehicle routes 120 gives a high level of accuracy in forecasting vehiclespeeds for each type of vehicle over a specific road length at aspecific time on a predetermined calendar day. For a given type ofvehicle, summing the forecast average speeds over the plurality ofdefined road sections of a journey allows the calculation for expectedtotal driving time on a proposed journey. This is a useful measurebecause the total driving time in a day is restricted by law in manycountries, particularly for drivers of heavy goods vehicles and coaches.

FIG. 4 describes how vehicle routes are planned by the trafficscheduling system of FIG. 1. In this example, separate resources of acommercial heavy goods operation are regarded as the vehicle (primemover), the trailer and the driver. This approach to resource managementis useful because a round trip for a trailer carrying a delivery loadmay consist of a delivery to one or more locations and collection ofproduct from one or more locations, with such locations being visitedover one or more days and requiring a substantial total mileage to becovered. However, such a trailer may be pulled by more than one primemover and utilise more than one driver to complete the journey. Althoughthe example given is directed to commercial heavy goods, this is notintended to be limiting. The invention also applies to a multitude ofother fields, examples include aviation, rail, shipping, military oremergency services, where other types of separate resource, such asvehicles and crew, might be required. Preferred embodiments also includecommercial and non-commercial uses, in which it might only be necessaryto monitor either the vehicle or the trailer.

The input parameters 610 for a preferred initial routing and schedulingalgorithm 450 include, but are not be limited to: data from the RoadTimetable 110, characteristics and availability data 410 of the vehicle;trailer and driver, depot locations 430; customer orders and constraints420; initial time and distance matrix 440 between all customers droppoints, collection points and the depot locations. The distances of thetime and distance matrix 440 are calculated by means of an electronicroad map using the shortest distance routes between relevant transitpoints.

These parameters are used by the initial routing and schedulingalgorithm 450 to provide initial vehicle routes. Therefore in preferredembodiments, information from the Road Timetable™ 110 is input to arouting and scheduling algorithm 450 to provide optimised routes basedon accurately predicted travel times. The routing and schedulingalgorithm 450 outputs the optimised route and predicted travel times toa scheduler interface unit 460. The scheduler interface unit 460 has aninterface allowing, where desired, manual adjustment of parameters andreprocessing of the routing and scheduling algorithm 450 to provideaccepted planned vehicle routes 470. Therefore it is not mandatory foran operator to accept the recommended routes(s) and he may instead wishto impose criteria, route sections and/or entire routes. In thisembodiment, the accepted vehicle routes 470 are the basis for both thefleet performance reporting 480, via incorporation into the post-tripdata 170, and any subsequent dynamic vehicle re-planning 130.

In the initial routing and scheduling algorithm 450 vehicle speed isinput via parameter 410 and is applied to calculate the travels from thetime and distance matrix 440. The application of Road Timetable™information 110 as a parameter in the initial routing and schedulingalgorithm 450 allows speeds along the route considered in the algorithmto be represented as a forecast speed for each specific road length atthe appropriate time in the relevant day of the week. The application ofthe Road Timetable™ information 110 in this way may make one or moreroutes unfeasible owing to the available drivers time input as one ofthe characteristics and driver availability parameters 410. Under suchcircumstances the algorithm will utilise specific operations researchtechniques, such as parallel insertion or Tabu search (shown later inFIGS. 12 & 15 respectively), to reallocate customer orders and customercollections to alternative vehicles.

For implementation reasons, a skilled person may decide to process RoadTimetable information 110 as a further phase performed after an initialprocessing of the vehicle routing and scheduling algorithm 450, as willbe described in more detail hereinafter. A skilled person willappreciate there are other ways of incorporating Road Timetable™information 110 into the routing and scheduling process.

FIG. 5 illustrates functions of the live traffic delay reporting stage140 which compares the actual (real time) traffic speeds from individualvehicle probes providing Floating Vehicle Data™ 210 with the forecasttraffic speed (by type of vehicle) reported on the Road Timetable™ 110.

The Traffic Alert Generator™ module 550 is the comparison and qualitycontrol routine from which the live delay reporting information 560 isgenerated. This module can identify unpredicted traffic delays as wellas improvements in traffic speeds having regard to the record in theRoad Timetable. In this embodiment, the Traffic Alert Generator™ 550first selects vehicle probes, preferably based on a probability functionreflecting the likelihood of the vehicle being on the relevant roadsection, to determine in real time from the selected vehicle probesspecific aspects of Floating Vehicle Data 210. In this example, thecriteria sampled include the traffic speed by vehicle type over aspecific road section at a specific time of the day. These criteria arecompared with the forecast speed by type of vehicle on the correspondingroad section at the appropriate time on the same day from the RoadTimetable 110. Any significant deviation is indicated by the TrafficAlert Generator to the Congestion Scheduler by means of traffic delayincident reporting 540 and recorded within the Traffic Alert Generatorfor live delay reporting 560 to either the Vehicle Scheduler 260 ordirect to a driver 570.

The actual live data obtained from the vehicle probes or other sensordata 580 is compared with the predicted speed held in the CongestionScheduler™ 530 and any significant variance reported back to the TrafficAlert Generator 550 through the live delay reporting 560 system. TheCongestion Scheduler™ 530 is a database of known incidents which arelikely to cause traffic delays. The data on each incident recorded inthe Congestion Scheduler™ is obtained either from the public domain 510or from a source outside the public domain 520. An example of a sourceoutside the public domain is a police force providing an escort for aslow moving wide load, such a source typically being able to providespeed and route information. The Congestion Scheduler™ 530 also includesa database of earlier incidents to apply ‘artificial intelligence’techniques to predict potential delays incurred by an incident from themoment one is detected. The Congestion Scheduler™ 530 is issued to usersas a separate database or is available on the Internet or the like. Whenthe reason for a traffic delay incident 540 is established and verifiedby other sensor data 580 or the traffic alert generator 550, then theinformation is passed to the live reporting system 560.

Following the determination of a traffic delay by the Traffic AlertGenerator™ 550, the live delay reporting system 560 sorts the delays bygeographic zone, for example by postcode (zip code or other areaclassification means) and reports these to drivers 570 in the relevantpost code (zip code or other geographical zone) by means of a suitablecommunication system, such as SMS or GPRS, possibly utilising HHT or PDA250 or a Radio Traffic System-Traffic Messaging Centre (RDS-TMC). Thelive delay reporting system 560 also reports the geographicallyclassified delays to vehicle schedulers in step 260. Where a vehiclescheduler is a person the delay may be reported, for example, direct toa desk top computer in order that they may take-on-route vehiclere-planning 130. Where the scheduler is a computer implemented system,the delay may be reported to an appropriately figured ApplicationsProgrammer Interface (API), for example to the dynamic vehiclere-routing module 130 of FIG. 1.

All incidents logged in the Traffic Alert Generator® 550 are monitoredby means of Floating Vehicle Data 210 until the incident is cleared.This type of historic data is also maintained in the database to be usedas part of an ‘artificial intelligence’ system to predict the length, intime, of any incident on a specific journey. By comparing real timeFloating Vehicle Data 510 indicating actual vehicle speed over aspecific road section at a specific time of day on a specific day of theweek with the forecast vehicle speed calculation in the Road Timetable™110, which is classified in the same way, unpredicted traffic delays orunpredicted improvements in traffic speeds are identified as occurrenceswhich produce a significant variation. The identification, verification,calculation and reporting of such occurrences or incidents, withreasons, to users or route-planning/re-routing applications is a usefulservice.

FIG. 6 describes the dynamic vehicle re-planning process 130 which isemployed when significant unpredictable traffic delays occur. Suchre-routing may be necessary in the event of unpredicted traffic delaysin commercial heavy goods vehicles for example in order to eitherachieve the customer service levels required or to maximise the drivers'potential driving time within recognised legal limits, if any apply.However, as noted above, this is not limited to commercial heavy goodssystems. Dynamic vehicle re-planning could feasibly be of use in avariety of other systems including the examples noted above. Inpractice, a maximum tolerable length of unpredictable delay ispredetermined and when this threshold is exceeded a re-planning processis initiated. The value of the threshold in time depends on theapplication.

From a knowledge of vehicle routes in use 470, unpredictable livetraffic delays reported by geographical zone 560 and the existingvehicle scheduling parameters 610 it is possible to re-route vehiclesalready embarked upon planned journeys using a dynamic vehiclere-routing and scheduling algorithm 620. The purpose of the dynamicre-routing and scheduling algorithm 620 is to provide a new route forundertaking all planned stops for any vehicle which is subject to anunpredicted traffic delay. This process depends upon being able toindicate the current position, direction and speed of a delayed vehicleby means of a probe and live vehicle progress monitoring 150.

The dynamic vehicle re-routing and scheduling algorithm 620 determines anumber of new route options by means of ‘artificial intelligence’ in apredetermined priority order for each vehicle effected by an unscheduledtraffic delay or improvement in traffic speed above that forecast in theRoad Timetable™ 110 used in the calculation of the original pre-eventplanned routes 470. The dynamic vehicle re-routing and schedulingalgorithm 620 may consider, for example, one or more of the followingoptions in the event of a delay:

-   -   Extending the drivers driving and working time to maximum        permitted hours in that day or the next day.    -   Despatching another driver (with sufficient driving and working        time available) to a pre-selected point to relieve the first        driver and complete the work.    -   Deleting one or more collection and using another vehicle        combination to undertake this work.    -   Delaying a non-critical customer drop until the next day.    -   Returning a customer drop, duplicating the order picking and        sending another vehicle combination out later to undertake the        delivery. Returning the original order to stock upon return of        the delayed vehicle combination.    -   Dropping the trailer at pre-selected point for another driver to        collect and complete the work (including drivers of third-party        operators).    -   Dropping the trailer at pre-selected point and asking the        customer to collect it and deliver the load (for example if a        third-party logistics firm undertakes the collection and        delivery for the customer).

The dynamic re-routing and scheduling algorithm 620 will presentalternative solutions to a vehicle scheduler interface 607. Thescheduler interface 607 confirms the recommended changes or can selectan alternative. Once the vehicle scheduler 607 has confirmed a selectionthe dynamic vehicle re-planning module 130 will communicate to thedrivers concerned 250 actions to taken by the selected communicationmeans, for example, SMS or GPRS.

The dynamic re-routing and scheduling algorithm 620 stores the selectedchanges to track the progress of the changes at selected time intervals.The stored changes are also available in the database for the‘artificial intelligence’ function. The tracking of the vehicle (“primemover”) and the load (“trailer”) are preferably undertaken separately,in accordance with the separate consideration of these entities in there-routing and scheduling algorithm 620 (and the routing algorithm 450).This allows efficient routing and scheduling when for example a newprime mover collects a trailer and completes the work or another driveris despatched to complete the work. In the event that progressmonitoring of a change shows, further delays outside the acceptedparameters then an exception message will recommend to the scheduler 460that the route is re-planned again. This process may be reiterated foreither a single vehicle or vehicle-load combination as well as formultiple vehicles and vehicle-load combinations.

Following the identification of a significant unpredicted trafficvariation the application of the on-route vehicle re-planning, by meansof a combination of dynamic vehicle routing and scheduling techniquesand, optionally, ‘artificial intelligence’ techniques together withcommunications to the vehicle and the monitoring of the vehicle progress(or vehicles progress) after the route re-planning process provides asignificant increase in performance with preferred embodiments.

FIG. 7 describes the live vehicle monitoring system 150 which isrequired in order to both determine the existence and extent of anyunpredicted traffic delays and to confirm the location, direction andspeed of the vehicle for on-route vehicle re-planning and monitoringrequirements.

The vehicle scheduler 260 knows the planned vehicle route 470 and checksthe progress of any vehicle on a pre-defined vehicle route 470. This isachieved using live tracking through a data collection point 240receiving on-board information 230 from the vehicle probes on either (orboth) a vehicle 710 or a trailer 720. This live tracking data isrequired for the scheduler to map the progress of a vehicle and/or thetrailer 150 and to determine whether to undertake dynamic vehiclere-planning 130 in the event of a traffic delay or improvement. Livevehicle monitoring also allows the vehicle scheduler to confirm that avehicle or trailer is heading towards or is in a reported traffic delay.

FIG. 8 identifies the post trip data 170 requirements and is essentiallya feedback loop providing up to date data for the Road Timetable™ 110.Post trip data 170 is collected from two sources: firstly, floatingvehicle data collection 810, for example from the vehicle probes eithercollected live or stored on the vehicle and downloaded as required andsecondly, data from the dynamic vehicle re-planning 130 process. Alldata collected is validated 820 and then presented in a post tripdatabase 170. The post trip data is subsequently used to both up datethe Road Timetable™ 110 and to provide fleet performance reporting 480including comparing actual activity from the Floating Vehicle Data 810with the planned vehicle routes 470.

The activities of collection, validation and application of the posttrip data facilitate updating of the Road Timetable™ 110. This processalso measures the quality of information from the Road Timetable™ 110,when there were no unpredicted incidents, by virtue of it being ameasure of the difference between the predicted traffic speed asindicated in the Road Timetable™ 110 and the actual traffic speedsachieved over a specific road length at specific times of the day for aparticular day of the week. The post trip data 170 is also used as aquality check upon the data initially presented and used.

FIGS. 9-18 show in more detail a preferred embodiment for a method andsystem for traffic planning and dynamic vehicle re-planning.

With reference to FIG. 9, the initial data scheduling parameters 610 areused to run a primary algorithm 910 and then a secondary algorithm oralgorithms 920. This provides initial results 930. These initial results930 are then subject to consideration by the scheduler interface 460using configured data 940 and/or adjusted results 950. There is then theoption to use either or both the initial results 930 or the adjustedresults 950 as the input data for a tertiary algorithm 960 or algorithms970. These tertiary algorithms may represent further improvement phasesso as to further modify the results previously achieved. Alternativelythey may also combine new data 980 (which may, for example, include livedelay reporting 560 and/or live vehicle progress monitoring 150),enabling previous results 930 and 950 to be modified in accordance withchanges in circumstances, for example to enable dynamic vehiclere-planning 130.

FIG. 10 illustrates the input data requirements for deriving a plannedvehicle route 470. These include but are not limited to:

-   -   a distribution depot 1010 referenced by location and activities;    -   the territory broken into geographical zones by a number of        postcodes or other means 1020;    -   customer database 1030 giving for example, address, access        times, access restrictions and type of mechanical handling        equipment if required;    -   data on vehicle speeds 1040 combined with a map 1050 referred to        herein as a road timetable 110;    -   the use of depot locations 430 and road timetable 110 to produce        a time and distance matrix 440;    -   a table of orders classified into priorities by, for example,        customer grouping or day of the week for delivery 1060;    -   products data 1070 classified for example by priority of        delivery or amount;    -   policies and procedures 1080 which for example, outline vehicle        loading restrictions for each product group;    -   operating rules 1090, either for the product (for example,        temperature at which the product must be carried), or for the        vehicle (for example, weight restrictions and lorry bans);    -   vehicle availability 10100 described for example, by vehicle        type, carrying capacity and/or operating shifts for which they        are available for use;    -   driver availability 10110 described for example, by vehicle        licence class, training level in mechanical handling equipment        and/or shift availability (according to contracts of employment        and prevailing drivers' hours rules);    -   trailer availability 10120 described for example, by carrying        capacity or specificity of goods.

This combination of data may then be input into the routing andscheduling algorithm 450, which may be a series of algorithms 1130 forexample a primary algorithm 910 and a secondary algorithm 920 or furtheralgorithms. Such algorithms may for example be a sequential insertionbased algorithm or a parallel insertion based algorithm depending onpreference.

FIG. 11 displays a possible sequential insertion based algorithm whichmight be used as a primary algorithm 910. This utilises a series ofsequential questions answered by reference to the input data shown inFIG. 10. Beginning at start 1110 a first question is asked 1120. Is aseed order available? A seed order is an unscheduled customer order inthe furthest geographical zone from the depot. If the answer is no thealgorithm stops 1130 as there is no order to process. If the answer isyes, the algorithm moves on to question 1140, . . . is a vehicleavailable? If the answer is that there is no vehicle available, theorder is added to a list of orders not scheduled 1150. If the answer isyes the algorithm checks if the order can be delivered 1160. Again, ifthe answer is no as the order cannot be delivered it is added to a listof orders not scheduled 1150. If the answer is yes the algorithm checksif the trailer capacity is full 1170. If the answer is yes, the trailercapacity is full, this may be filed as a preliminary route 1180. If theanswer is no the algorithm looks to see if the driver shift is fullyutilised 1190. If the driver shift is fully utilised, the algorithmchecks if a smaller vehicle is available 11100. If the answer is no thenthis may be filed as a preliminary route 1180. If the answer is yes thealgorithm returns to the question 1160 and moves through the processagain. Alternatively if the answer to question 1190 is no then question11120, is there another order in the zone, is asked. If the answer isyes the algorithm returns to question 1160. If the answer is no this isthen filed as a preliminary route 1180.

FIG. 12 represents a possible parallel insertion based algorithm whichmay be used as an alternative, or in addition to, the sequentialinsertion based algorithm shown in FIG. 11. Beginning at start 1210 aseed order is selected 1220. The algorithm then checks if the vehiclecapacity is available 1230. If there is no vehicle capacity availablethis is added to a list of orders not scheduled 1240. If capacity isavailable the algorithm then checks to see if the order can be delivered1250. If the answer is no the selected seed order 1220 is added to alist of orders not scheduled 1240. If the answer is yes the algorithmchecks if all vehicles are full 1260. If the answer is yes this may befiled as a route 1270. If the answer is no the algorithm checks whetherthere are unscheduled orders 1280. If the answer is yes the algorithmreturns to question 1250 and moves through the process again. If theanswer is no the algorithm checks if the order could be inserted 1290.If the answer is no the algorithm stops 12100 as the order cannot bedelivered. If the answer is yes the algorithm either selects the nextorder in the zone or the next seed order 12110, and returns to question1220.

Once filed as a route the scheduler interface 460 may accept theseroutes. In which case routes 1180 or 1270 will become a planned vehicleroute 470. A scheduler interface 460 may also decide to accept a stopresult 1130 or 12100, or an addition to the list of orders not scheduled1150 or 1240. Alternatively, the scheduler interface may decide toutilise one or more improvement phases, as described having regard toFIGS. 13-15. Each improvement phase will aim to reduce overall operatingcosts further and be targeted at a specific new requirement orrequirements. Each improvement opportunity may require a specificoperations research technique to provide an acceptable solution whichreduces costs.

FIG. 13 illustrates a number of options for improving the first solutionproduced by employing one or more improvement phases. Type oneimprovement phase 1310 involves running an additional algorithm in orderto improve the solution already provided. When used alone this may be atertiary algorithm 960 or may involve multiple tertiary algorithms, forexample 960 and 970. An example of such algorithm might be a Tabu searchalgorithm (see FIG. 15) and/or a simulated Annealing algorithm (see FIG.14). When type one improvement phase 1310 is used with an additionalimprovement phase, the second algorithm may involve repeating theinitial algorithm or algorithms 10130 with modified data. This may beinstead of or in addition to the use of a tertiary algorithm 960 oralgorithms 960 and 970.

A type two improvement phase 1320 involves manual intervention, changingor adding to the input data to produce configured data 940. This maythen be used to rerun the algorithms already in use 10130. Note that asan alternative embodiment to manual intervention a type two improvementphase could instead be based around a computer facilitated intervention.

A type three improvement phase would involve selecting a depot for whichthe delivery is to be made to each customer 1330. This may be inresponse to changes in demand or stock or resource availability 1340. Inthis improvement phase a customer order 420 may be split and delivereddirectly (or indirectly) from two or more depots.

Type four improvement phase 1350 involves correcting the input datawhere alternatives are known and data gathered upon the previous vehicleruns. For example this would include the use of telematics data 1360 tocorrect the speed of a particular type of vehicle of a defined stretchof road at a specific time of day as recorded in a road timetable 110(see FIG. 17).

Type five improvement phase 1370 assesses the impact of usingalternative resources 1380 for example different vehicle sizeconfigurations of specific changes in input data such as the impact ofcustomer drop time delays.

Type six improvement phase 1390 alters the data so as to assess theimpact of the changes in customer demand 13100.

By adapting the data and running multiple algorithms as described abovea variety of commercial traffic scheduling issues can be addressed viagenerating the customer specific data entry at the front end, suitableselection of algorithm running times (to obtain speed of response) and asecurity of the solution being addressed by a selection as a requirementby the user, each requirement being solved by a specific algorithm andproviding specific outputs.

The various algorithms allow the user the option of limiting cost bymeans of either minimising the number of vehicles used or by minimisingthe number of miles travelled. Each algorithm is designed to prepare thedata then once set up by the operator have a run time of less then oneminute on present computing systems for a 500 customer order problem andless than two and a half minutes for a 1000 customer order problem.FIGS. 14-18 show a variety of algorithms which may be used in practice.

FIG. 14 represents a possible simulated annealing improvement algorithm.Starting at 1410 the total running time is first set 1420. A scheduledorder is selected at random 1440 from a list of preliminary routes 1430.The algorithm checks to see if it is a feasible insertion 1450. If notand there is still time available 1470 another order is selected atrandom 1440 and the process begins again. If there is a feasibleinsertion 1450 the algorithm then checks if this route is better 1460.If not and there is time available 1480 then the algorithm returns to1440 and carries on. If there is no time available the algorithm stops1490. If the route 1460 is better the algorithm then checks if the moveis allowed 14100. If it is allowed it is then filed as a route 14110. Ifnot the algorithm checks if the set time available is finished 1470 byreturning to 1440 if there is time available or stopping 1490 is thetime available is finished.

FIG. 15 represents a possible Tabu Search improvement algorithm.Starting at 1510 a list of preliminary routes 1520 is used to reschedulethe routes against objectives in a table 1530. The total running time ofthe first Tabu search has been previously set 1540 and if the timeavailable is then finished the algorithm comes to a stop 1550. If timeavailable is not finished 1560 the algorithm then selects the best movefrom the objective table rules 1570—these are a set of key parametersdefined by the scheduler. The algorithm checks if this move is allowed1580. If not the algorithm returns to 1570 to select the best remainingrules in the objective table rules. If the move is allowed the algorithmcompletes the move 1590. This is then filed as route 15100. More Tabuare then set by changing the key parameters and the algorithm returns to1530 and moves through the process again.

FIG. 16 represents an algorithm used to calculate the impact ofpotential traffic congestion. Starting at 1610 a route is selected 1620from a file of preliminary routes 1630. Historic time and mileageforecasts 1640 are built up by subjecting data derived from on boarddata collection 230 to telematics data analysis 16100 to produce a roadtimetable 110. The historic time and mileage forecasts 1640 are thenderived from this road timetable 110. A comparison of this route is madewith a start time and mileage forecasts 1640 to check if the route isnow feasible 1650. If the route is feasible it is filed as a new route1660 and the algorithm returns to 1620 selecting a new route to repeatthe process. If the route is not feasible 1650 the route is recalculatedusing an improvement algorithm 1660. The resultant data is then insertedinto the time and mileage matrix 1670, the system then returning to 1640to repeat the process. If after recalculating with an improvement ofalgorithm 1660 all the routes are checked 1680 then the system stops1690. If all the routes are not checked the system returns to 1620,selecting a new route to repeat the process.

FIG. 17 illustrates an algorithm for calculating the impact of customerdrop time delays. Starting at 1710 a customer order is selected 1720from a file of preliminary routes 1730. Data collected from on boarddata collection 230 is subjected to telematics data analysis 1740 andcombined with customer parameters 1750 to produce a customer drop timedatabase 1760. The selected customer order is then fed into the customerdrop time database 1760. The algorithm then checks if the customer droptime is set to zero 1770. If it is, average fixed and variable drop timeassumptions are used 1780. If the customer drops time is not set to zerothen the actual data of the customer drop time is used 1790. In eithercase this produces customer drop time data 17100. Using this data 17100to indicate the time delay, the algorithm then checks if this ordercould be inserted 17110. If not the algorithm then returns to 1720selecting a new customer order and repeating the process. If, takinginto account the delay time, the order could be inserted 17110 the orderis then filed as a new route 17120 and the algorithm either stops 17130or returns to 1720 to select a new order to repeat the process.

FIG. 18 represents an algorithm which can be used for dynamic vehiclere-planning. Starting at 1810 a route is selected 1820 from a file ofcurrent routes 1830. The route selected is in an affected zone 1820. Theaffected zones are determined 1840 from the use of on board datacollection 230 and incident reporting 540 by the traffic alert generator550. The traffic alert generator 550 allows new time and mileage basedupon actual data to be inserted into the selected route 1850. Thealgorithm then checks if this new route is feasible 1860. If the routeis still feasible then the algorithm selects a new route 1870 andrepeats the process. If the change indicated by the traffic alertgenerator means that the selected route is now no longer feasible theroute is recalculated using an improvement algorithm 1880. The outputfrom this is then filed as a new route 1890. The algorithm then checksif all the routes are checked 18100. If not a new route is selected1870. If all the routes are now checked the algorithm stops 18110.

It can be seen then that through a combination of real time monitoringfrom a variety of sources, the use of historical traffic data, and theselection of appropriate modifications and algorithm manipulations,routes can be planned and dynamically adjusted, taking into account awide variety of different requirements, conditions and changingcircumstances. Preferred embodiments thus benefit from a combination ofthe predicted traffic speeds offered by the Road Timetable™ used inpre-event planning of vehicle routes and schedules and live vehicletracking which forms part of the live traffic delay reporting, whichtakes into account unpredicted traffic delays or improvements providingan opportunity for dynamic vehicle re-routing. In addition, thecollection of post trip data is used to refine future predictions.

Particular advantages of the preferred embodiments include collectionand application of traffic data for use in pre-event planning of vehicletrips and post-event real time re-planning in the event of anunpredicted traffic incident occurring while the vehicle is on itsplanned trip.

The various apparatus modules described herein may be implemented usinggeneral purpose or application specific computer apparatus. The hardwareand software configurations indicated for the purpose of explaining thepreferred embodiment should not be limiting. Similarly, the softwareprocesses running on them may be arranged, configured or distributed inany manner suitable for performing the invention as defined in theclaims.

1. A method of operating a traffic scheduling computer system forplanning journeys, each journey having a plurality of transit points,the method comprising: receiving scheduling criteria including transitpoint data; receiving map data, said map data comprising one or moreroutes, each route defined by a plurality of route-sections; receivingforecast speed information for a traffic unit on each saidroute-section, the forecast speed for a given route-section depending onhistorical speed data for that route-section at a predetermined time ona particular day; and planning a journey including a plurality oftransit points in dependence on the scheduling criteria and forecastspeed information.
 2. A method as in claim 1, wherein at least a portionof the planned journey is re-planned according to re-scheduling criteriaafter the traffic unit has embarked upon the journey.
 3. A method as inclaim 2, wherein said re-planning step is triggered in response to anunpredicted traffic event or operational failure.
 4. A method as inclaim 2, wherein one or more of said planning or re-planning stepsdepends on unpredictable event data.
 5. A method as in claim 4, whereinsaid unpredictable event data comprises live traffic reports.
 6. Amethod as in claim 4, wherein said unpredictable event data comprisesdata derived from live traffic monitoring.
 7. A method as in claim 1,wherein a first journey solution is determined in a first algorithmprocessing step and an improved journey solution is determined in afurther algorithm processing step.
 8. A method according to claim 1,wherein said scheduling criteria comprise one or more of: availabilitydata; distance data; time data; depot data; customer data; and productdata.
 9. A method according to claim 8, wherein said availability datacomprises availability data for one or more of: a prime mover; atrailer; and a driver.
 10. A method as in claim 3, wherein anunpredictable event is categorised according to a geographic region inwhich it occurs and information on the unpredictable event iscommunicated to traffic units associated with a relevant geographicalregion.
 11. A method as in claim 1, wherein said forecast speedinformation for a route-section is recorded and compared with actualspeed data for that route-section in order to provide a measure ofreliability.
 12. A method as in claim 1, wherein said forecast speedinformation for a route-section is recorded and compared with actualspeed data for that route-section in order to feedback an input to thetraffic scheduling system.
 13. A method as in claim 1, whereinhistorical speed data is acquired by means of floating vehicle datacollection units or other mobile data collection means.
 14. A method asin claim 3, wherein live traffic monitoring is performed by means offloating vehicle data collection units or other mobile data collectionmeans.
 15. A method as in claim 13 or 14, wherein a floating vehicleprobe is selectively activated for montoring based on a probability ofthe traffic unit carrying the probe being on a predeterminedroute-section.
 16. A computer program product comprising program codemeans adapted to control the method of claim
 1. 17. A computer systemfor scheduling traffic capable of planning journeys each having aplurality of transit points, the system comprising: means for receivingscheduling criteria including transit point data and map data, said mapdata comprising one or more routes, each route defined in terms of aplurality of route-sections; a data repository comprising historicalspeed data for each route-section, historical speed data for aparticular route-section being represented for a predetermined time on aparticular day; means for generating forecast speed information for atraffic unit on each said route-section based on said historical speeddata; and processing means for planning a journey including a pluralityof transit points in dependence on said scheduling criteria and forecastspeed information.